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Executive  Summary 


Today’s  vessel  traffic  services  are  being  pressured  to  reduce  implementation  costs  and 
annual  operating  costs.  Both  can  be  reduced  by  automating  some  functions  of  the 
vessel  traffic  service.  Automation  requires  that  new  methods  be  used  to  provide 
navigation  information  more  accurately  and  quickly  to  the  new  electronic  navigation 
technology  being  installed  aboard  the  ships  of  vessel  traffic  service  participants.  Over 
time,  vessel  traffic  services  can  change  the  way  waterways  management  is  achieved. 
Change  is  difficult  to  achieve  quickly  in  the  marine  world.  Years  of  coordinated  effort 
will  be  required  to  reshape  the  marine  infrastructure  to  conform  to  a  new  vision.  This 
report  is  a  brief  sketch  of  one  possible  course  towards  the  automation  of  vessel  traffic 
service  (VTS)  functions. 

This  report  introduces  and  describes  the  concept  of  “voiceless  vessel  traffic  services’’ 
and  the  part  that  wireless  digital  technology  can  play  in  future  VTS  automation.  It  also 
presents  the  engineering  and  implementation  considerations  that  are  needed  to 
facilitate  the  introduction  of  a  concept  called  “digital  navigation  safety  broadcasting” 
into  the  marine  community.  The  common  thread,  in  both  concepts,  is  the  free  and  open 
distribution  of  vessel  traffic  service  information  using  automated  processes. 

Automating  VTS  functions  can  reduce  the  cost  of  operating  vessel  traffic  services. 
Automation  is  a  way  for  the  USCG  to  reduce  the  percentage  of  its  annual  budget 
supporting  VTS  systems,  or  as  a  way  to  make  establishment  and  operation  of  VTS-like 
systems  more  attractive  to  potential  partners  in  the  private  sector.  The  first  benefit 
would  occur  through  a  reduction  of  the  actual  number  of  USCG  staff  needed  to  operate 
a  USCG  VTS.  This  represents  direct  cost  savings.  The  second  benefit  would  allow  the 
USCG  to  avoid  future  implementation  costs  by  encouraging  alternative  non-federal 
deployments  of  semi-automated  VTS  systems  in  ports  needing  VTS-like  systems. 

Under  suitable  conditions,  the  USCG  could  also  realize  direct  savings  by  adding 
automated  VTS  capabilities  to  existing  VTS  systems  and  transferring  operation  of  these 
“reduced-operating-cost”  services  to  willing  partners. 

The  concept  of  voiceless  vessel  traffic  services  is  based  on  two  assumptions.  First, 
that  improving  the  flow  of  navigation  information  will  improve  the  pilot’s  decision  making 
process.  Second,  that  information  can  flow  automatically  between  the  vessel  traffic 
service  computers  and  the  computer  systems  aboard  each  ship.  The  existence  of  such 
a  capability  could  significantly  reduce  the  need  for  voice  communications  between  the 
vessel  traffic  service  operator  and  each  ship’s  pilot  or  master.  Removing  the  vessel 
traffic  service  operator  from  the  immediate  information  flow  significantly  reduces  the 
operator’s  workload.  Introducing  electronic  automation  increases  the  quantity  and 
quality  of  information  that  can  be  provided. 

Implementation  of  the  voiceless  vessel  traffic  service  concept  will  require  either  the 
development  of  new  or  the  identification  and  review  of  existing  processes,  standards, 
and  methods  that  can  be  used  to  create  the  service.  For  example,  a  review  of  how 
information  is  presently  entered  into  the  vessel  traffic  service  databases  will  be  needed 
to  affirm  that  the  information  in  the  database  undergoes  sufficient  validation  and  that  it 
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is  suitable  for  automated  distribution.  Also,  an  assessment  of  the  sensitivity  of 
information  in  the  database  should  be  done  to  determine  if  open  and  automatic 
distribution  of  that  information  will  compromise  the  present  levels  of  port  security. 

The  voiceless  vessel  traffic  service  model  suggests  the  use  of  two  complementary 
methods  for  the  automated  distribution  of  information,  wireless  digital  communications 
and  wireless  digital  broadcasting.  Two  factors  favor  the  use  of  broadcasting  for  the 
distribution  of  navigation  information.  The  first  factor  is  the  cost  to  the  user.  The  user 
needs  to  make  only  a  “one-time”  investment  in  equipment.  The  second  factor  is  the 
ability  of  broadcasting  to  simultaneously  distribute  all  the  information  to  an  unlimited 
number  of  users.  Broadcast  capacity  is  independent  of  user  demand.  Wireless  digital 
communication  is  sensitive  to  user  demand.  Communications  channels  can  become 
saturated  and  fail  as  demand  increases. 

A  simple  model  of  a  navigation  safety  broadcast  system  was  developed  and  used  to 
help  identify  areas  requiring  development.  The  following  were  found  to  be  necessary 
to  create  a  simple  voiceless  VTS  navigation  safety  broadcast  design;  vessel  traffic 
service  database  search  process,  broadcast  site  router  process,  broadcast  scheduler 
process,  and  broadcast  monitor  process.  Also,  two  standards  describing  the  operation 
of  the  broadcast  system  are  needed.  The  first  standard  would  describe  the  internal 
system  message  and  command  structure  of  the  system.  This  would  be  used  to  design 
and  maintain  the  system.  The  second  standard  provides  everything  a  potential 
equipment  manufacturer  would  need  to  know  about  the  broadcast  signal  in  order  to 
manufacture  user  equipment  for  voiceless  VTS. 

This  report  raises  issues  concerning  the  presentation  of  VTS  information  to  the  pilot. 
Automating  the  distribution  of  information  reduces  voice  radio  communications  between 
the  vessel  pilot  and  vessel  traffic  service  operator.  This  is  viewed  as  a  workload 
reduction  for  the  operator,  but  it  could  represent  a  shift  of  the  “vessel  traffic  service 
workload”  to  the  pilot.  The  significance  of  this  shift  is  not  well  understood.  The  impact 
of  automation  on  the  pilot  as  a  result  of  this  switch  from  aural  distribution  to  visual 
display  needs  investigation.  A  future  study  is  needed  to  investigate  the  change  in 
piloting  workload,  impact  on  marine  safety,  and  benefits  of  voiceless  vessel  traffic 
services.  The  pilot’s  views  on  the  information  content  and  shipboard  presentation  are 
needed  to  develop  the  most  appropriate  shipboard  system. 

Future  USCG  research  should  include  a  demonstration,  “voiceless  vessel  traffic  service 
test  bed,”  conducted  with  the  cooperation  of  an  operating  USCG  vessel  traffic  service 
and  the  marine  pilots  association  working  in  their  vessel  traffic  service  area.  This 
demonstration  would  provide  an  opportunity  to  develop  and  evaluate  the  needed 
voiceless  vessel  traffic  service  processes  and  standards.  It  would  also  provide  an 
opportunity  to  work  with  the  pilots  to  develop  the  true  information  requirements  for  the 
content  of  the  navigation  safety  broadcast.  The  demonstration  would  serve  as  a 
vehicle  for  standards  and  equipment  development  in  cooperation  with  the  industry  that 
would  support  future  operational  deployment  of  voiceless  vessel  traffic  services. 


1.0  Introduction 


Today’s  vessel  traffic  service  managers  are  being  pressured  to  reduce  implementation 
costs  and  annual  operating  costs.  Both  can  be  reduced  by  automating  some  functions 
of  the  vessel  traffic  service.  Automation  requires  that  new  methods  be  used  to  provide 
navigation  information  more  accurately  and  quickly  to  the  new  electronic  navigation 
technology  being  installed  aboard  the  ships  of  vessel  traffic  service  participants.  Over 
time,  vessel  traffic  services  can  change  the  way  waterways  management  is  achieved. 
Change  is  difficult  to  achieve  quickly  in  the  marine  world.  Years  of  coordinated  effort 
will  be  required  to  reshape  the  marine  infrastructure  to  conform  to  a  new  vision.  This 
report  is  a  brief  sketch  of  one  possible  course  towards  the  automation  of  vessel  traffic 
service  (VTS)  functions. 

Marine  transportation  is  being  reshaped  by  innovations  made  possible  through  the 
application  of  computers,  communications,  and  other  information-related  technologies. 
The  most  direct  benefits  are  measured  in  improved  safety,  reduced  operating  costs, 
increased  capacity,  and  an  improved  environment.  In  view  of  the  magnitude  and 
potential  impact  of  the  benefits  that  are  attainable  through  the  introduction  of  advanced 
transportation  technologies,  the  Department  of  Transportation  (DOT)  adopted  the 
objective  to  “accelerate  technological  advances  to  make  our  transportation  system 
more  efficient,  environmentally  sound,  and  safe”  in  the  DOT  Strategic  Plan  of  1994. 

This  report  introduces  and  describes  the  concept  of  “voiceless  vessel  traffic  services” 
and  the  part  that  wireless  digital  technology  can  play  in  future  vessel  traffic  service 
automation.  It  also  presents  the  engineering  and  implementation  considerations  that 
are  needed  to  facilitate  the  introduction  of  a  concept  called  “digital  navigation  safety 
broadcasting  (NSB)”  into  the  marine  community.  Digital  distribution  will  enhance  the 
performance  of  vessel  traffic  services  and  reduce  the  costs  associated  with 
establishing,  operating,  and  maintaining  a  VTS.  The  report  also  contains 
recommendations  concerning  areas  needing  further  research  and  development.  The 
principles  of  the  digital  navigation  safety  broadcast  concepts  presented  in  this  report 
can  be  applied  to  any  VTS  or  VTIS  (vessel  traffic  information  service)  system  presently 
in  operation  or  planned  for  future  operation  in  the  United  States.  At  the  present  time, 
none  of  the  existing  USCG  VTS  systems  provide  for  the  automated  distribution  of 
navigation  information  to  marine  users  or  to  the  shipboard  systems  they  use. 

The  purpose  of  the  NSB  is  to  automatically  provide  vessel  pilots  with  information 
gathered  by  the  VTS.  This  would  be  accomplished  by  coding  the  information  into  a 
wireless  signal  that  would  be  broadcast  throughout  the  VTS  “vessel  traffic  service  area 
(VTSA).  Such  information  might  include  the  position,  course,  and  speed  of  large 
vessels  in  the  VTSA,  the  actual  water  depth  at  key  locations,  or  abnormal  water  current 
conditions.  This  automation  is  expected  to  significantly  reduce  the  need  for  voice 
communications  between  vessels  and  the  VTS  operator,  making  more  radio  frequency 
time  and  conning  time  available  for  direct  communications  between  ships. 
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The  NSB  service  will  need  a  number  of  operating  features.  For  example,  each  discrete 
message  will  need  type  identification  to  allow  automatic  acceptance  or  rejection  by 
each  ship’s  navigation  system.  Mechanisms  to  clearly  identify  superseding  information 
will  need  to  be  included.  Measures  to  detect  errors  and  correct  errors  are  needed  to 
prevent  corrupted  information  from  entering  the  ship’s  navigation  system.  Measures  to 
guarantee  the  integrity  and  validity  of  information  will  protect  the  system  from  being 
degraded  by  unintentional  or  intentional  interference  sources. 

General  acceptance  and  implementation  of  VTS  digital  navigation  safety  broadcasts 
and  the  shipboard  equipment  that  uses  the  broadcast  information  would  significantly 
reduce  the  workload  experienced  by  today’s  vessel  traffic  operators.  This  could  be 
translated  into  reduced  VTS  operating  costs,  increased  port  efficiency,  and  increased 
safety.  Automating  timely  VTS  information  flow  and  presentation  should  also  reduce 
the  marine  pilot’s  workload,  but,  as  this  report  suggests,  this  aspect  of  voiceless  VTS 
requires  more  investigation. 

Automating  VTS  functions  can  reduce  the  cost  of  operating  vessel  traffic  services. 
Automation  can  be  viewed  as  a  way  for  the  USCG  to  reduce  the  percentage  of  its 
annual  budget  supporting  VTS,  or  as  a  relatively  inexpensive  approach  to  watenvays 
management  that  would  be  more  attractive  to  partners  desiring  to  fund  the 
establishment  and  operation  of  VTS-like  services.  The  first  option  would  occur  through 
a  reduction  of  the  actual  number  of  USCG  staff  needed  to  operate  a  USCG  VTS.  This 
represents  direct  cost  savings.  The  second  option  would  allow  the  USCG  to  avoid 
future  implementation  costs  by  encouraging  alternative  non-federal  deployments  of 
voiceless  VTS  systems  in  ports  needing  VTS-like  services.  Under  suitable  conditions, 
the  USCG  could  also  realize  direct  savings  by  adding  voiceless  VTS  capabilities  to 
existing  VTS  and  transferring  operation  of  these  “reduced-operating-cost”  services  to 
willing  partners. 

Sections  of  this  report  contain  an  overview  of  the  voiceless  VTS  concept  and  how 
digital  broadcasting  might  be  deployed.  The  reader  interested  in  a  quick  overview  of 
the  voiceless  VTS  concept  should  read  sections  2.0  and  2.1 .  A  similar  overview  of  the 
digital  Navigation  Safety  Broadcast  concept  can  be  obtained  by  reading  sections  3.0, 
3.1,  3.1.1,  and  3.1.3.  The  remaining  sections  of  the  report  discuss  specific  issue, 
process,  standard,  or  method  details. 
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2.0  Background 


In  the  United  States  there  are  a  number  of  federally  funded  vessel  traffic  services 
(VTS).  Vessel  traffic  services  are  established  and  operated  to  improve  navigational 
safety  and  protect  sensitive  marine  environments  in  areas  of  significant  marine  traffic. 

It  helps  determine  the  presence  of  vessels  in  and  around  ports,  and  it  provides 
information  to  vessels  on  such  matters  as  traffic,  tides,  weather  conditions,  and  port 
emergencies.  Under  the  authority  of  the  Ports  and  Waterways  Safety  Act  of  1972,  as 
amended,  the  U.  S.  Coast  Guard  operates  VTS  in  eight  ports  around  the  United  States. 
Operatioris  and  maintenance  costs  for  these  systems,  which  totaled  about  $19,000,000 
in  fiscal  year  1 995,  are  borne  by  the  U.  S.  Coast  Guard.  The  costs  are  not  passed  on 
to  the  ports  or  to  the  shipping  industry. 

Expansion  of  the  nation’s  VTS  facilities  is  now  being  considered  as  a  result  of  the  Oil 
Pollution  Act  of  1990  (P.L.  101-380),  passed  after  the  1989  EXXON  VALDEZ  oil  spill 
and  subsequent  spills  in  the  waters  of  Rhode  Island,  the  Delaware  River,  and  the 
Houston  ship  channel.  This  act  directed  the  Secretary  of  Transportation  to  prioritize 
the  need  for  new,  expanded,  or  improved  VTS  systems  in  U.  S.  ports  and  channels. 

The  results  of  this  study.  Port  Needs  Study  (Maio  et  al.,  1 991 ),  were  submitted  to  the 
Congress  in  March  1992.  The  U.  S.  Coast  Guard  presently  has  two  major  efforts 
underway  to  improve  and  expand  VTS  in  the  United  States.  The  first  is  “VTS  Upgrade.” 
This  is  an  effort  to  improve  the  existing  VTS.  The  second  is  “VTS  2000.”  This  is  a 
large  procurement  designed  to  expand  VTS  to  additional  ports.  In  addition  to  federally 
funded  and  operated  VTS,  the  private  sector  has  started  to  invest  in  “VTS-like”  systems 
in  areas  such  as  Los  Angeles/Long  Beach  and  Philadelphia/Delaware  Bay.  The  VTS 
at  Los  Angeles/Long  Beach  is  a  demonstration  of  how  a  partnership  between  the  U.  S. 
Coast  Guard  and  private  sector  can  be  formed  to  accomplish  the  goals  of  a  VTS. 

A  primary  function  of  a  United  States  Coast  Guard  (USCG)  vessel  traffic  service  is  to 
gather  information  that  is  of  significance  to  marine  navigation.  The  modern  USCG  VTS 
maintains  much  of  this  information  in  computer  systems.  The  VTS  operators  use  these 
computer  systems  to  service  information  requests  made  by  individual  pilots  over  voice 
communications  channels.  The  existing  VHF-FM  marine  radio  band  is  commonly  used 
by  the  VTS  operator  to  transfer  information  to  the  pilot. 

While  this  approach  is  successfully  used  today  to  distribute  navigation  information,  it 
does  require  knowledgeable  and  trained  people.  Voice  communications  do  limit  the 
amount  of  information  that  can  be  meaningfully  distributed.  The  simultaneous 
processes  of  gathering  and  distributing  information  accurately  create  a  challenging 
workload  for  even  the  most  experienced  VTS  operator.  A  study  of  VTS  operator 
workload  (Smith  et  al.,  1994)  pointed  out  that  attention  to  communications  was  the 
dominant  factor  that  determined  how  the  VTS  operator  scheduled  activities. 

The  marine  electronics  industry  continues  to  introduce  products  that  should  improve 
navigation  safety  and  efficiency.  The  introduction  of  these  products  aboard  vessels  is 
expected  to  increase  the  demand  for  timely  VTS  information.  For  example,  electronic 
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chart  systems  (ECS)  graphically  present  the  relationship  of  one’s  own  ship  with  respect 
to  the  geographic  surroundings.  Pilots  have  expressed  a  desire  to  view  the  movement 
of  other  ships  on  the  same  display.  This  would  provide  the  pilots  with  a  display  similar 
to  the  VTS  operator  display.  It  will  not  be  possible  for  the  VTS  operator  to  satisfy  the 
demand  for  this  detail  of  ship  information  using  the  present  voice  communication’s 
methods.  Such  a  demand  can  only  be  satisfied  by  improving  the  way  VTS  navigation 
information  is  distributed. 

2.1  Voiceless  VTS  -  Concept  Overview 

Introduction  -  The  concept  of  voiceless  VTS  is  based  on  two  assumptions.  First,  that 
improving  the  flow  of  navigation  information  will  improve  the  pilot’s  decision  making 
process.  Second,  that  information  can  flow  automatically  between  the  VTS  computers 
and  the  computer  systems  aboard  each  ship.  The  existence  of  voiceless  VTS  could 
significantly  reduce  the  need  for  voice  communications  between  the  VTS  operator  and 
each  ship’s  pilot  or  master.  Removing  the  vessel  traffic  service  operator  from  the 
immediate  information  flow  significantly  reduces  the  VTS  operator’s  workload. 
Introducing  electronic  automation  increases  the  quantity  and  qualify  of  the  VTS 
information  that  can  be  provided. 

The  voiceless  VTS  concept  and  the  information  it  automatically  provides  are  presented 
in  this  report  primarily  with  the  needs  and  operation  of  mandatory  VTS  participants  in 
mind.  Of  course  the  service  is  expected  to  also  service  the  needs  of  non-mandatory 
participants  as  well.  The  following  are  definitions  for  a  few  key  terms  used  throughout 
the  discussion  of  the  voiceless  VTS  concept: 

Vessel  Traffic  Service  (VTS):  Any  service,  implemented  by  a  competent  marine 
authority,  which  interacts  directly  with  vessel  traffic  and  in  response  to  that  traffic  in 
real  time  in  order  to  improve  the  safety  and  efficiency  of  traffic  and  to  preserve  the 
integrity  of  the  environment. 

Mandatory  Participant:  Vessel  required  by  33  CFR  Part  161  to  comply  with  VTS 
procedures  and  participate  in  a  VTS. 

Navigation:  The  process  of  planning,  recording,  and  controlling  the  movement  of  a 
craft  or  vehicle  from  one  place  to  another. 

Pilot:  The  pilot  is  responsible  for  safe  navigation  when  exercising  direction  and 
control.  The  U.S.  Supreme  Court  has  described  a  pilot  as  the  “temporary  master”  in 
regard  to  navigation.  The  pilot  normally  directs  and  controls  the  vessel’s 
maneuvering  and  is  subject  only  to  the  overriding  command  authority  of  the  master. 
Under  the  federal  system,  a  coastwise  vessel  may  be  piloted  by  its  master  or  mate  if 
the  officer  has  an  officer’s  license  pilotage  endorsement. 

Four  information  flow  models  are  used  below  to  build  and  explain  the  voiceless  VTS 
concept.  Each  of  these  models  represents  alternative  methods  for  acquiring  and 
presenting  information  to  the  ship’s  navigation  process.  The  first  model  depicts 
traditional  marine  navigation  in  the  absence  of  a  VTS.  The  second  model  represents 
marine  navigation  when  and  where  VTS  information  is  available.  The  third  model 
represents  the  change  to  marine  navigation  now  underway.  Some  of  the  traditional 
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navigation  tools  are  being  automated  and  more  timely  information  is  being  provided  to 
the  pilot.  The  technology  needed  to  support  the  third  model  is  being  produced  today. 
The  fourth  model  is  a  general  concept  of  how  the  navigation  process  could  gain  better 
access  to  VTS  information  in  the  future.  The  commercial  components  for  the  fourth 
model,  which  is  called  “voiceless  VTS,”  do  not  exist  today.  They  need  to  be  developed 
and  integrated. 

Model  1  -  The  pilot  uses  a  mix  of  shipboard  sensory  information,  personal  training,  and 
experience  to  successfully  complete  the  navigation  of  a  vessel.  Some  sensory 
information  is  taken  directly  from  shipboard  instruments,  such  as  a  gyro  compass,  while 
other  information,  such  as  latitude  or  longitude,  is  more  useful  when  a  navigation  tool  is 
used.  When  navigating  in  coastal  areas,  a  nautical  chart  provides  the  required 
backdrop  upon  which  to  present  information.  It  contains  the  geographic  information 
needed  to  support  pilot  decisions.  The  flow  of  sensor  information  directly,  or  through 
the  traditional  navigation  tools,  to  the  pilot  are  depicted  in  Figure  1. 


Figure  1-  Simple  model  of  traditional  marine  navigation  process 


The  circles  in  Figure  1  represent  the  human  processes.  These  circles  also  represent 
training,  experience,  and  knowledge  that  are  critical  to  successful  navigation,  but  that 
are  not  the  subjects  of  this  report.  This  report  is  primarily  interested  in  the  flow  of 
sensor  and  database  information.  The  arrows  represent  the  general  flow  of  information 
supporting  the  pilot’s  decision  making  process.  The  process  boxes  represent  the  tools 
that  also  play  an  important  part  in  the  pilot’s  decision  making  process.  Notice  that  the 
“shipboard  sensors”  serve  the  pilot  directly  as  well  as  the  navigation  process.  The 
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arrow  from  the  shipboard  sensors  directly  to  the  pilot  is  shown  heavier  to  represent  the 
timeliness  of  the  information.  The  arrow  from  the  traditional  navigation  tools  is  less 
heavy.  Sensor  information  processed  by  traditional  navigation  tools  tend  to  give  a  very 
good  record  of  where  the  vessel  has  been,  but  the  information  is  not  timely.  The  direct 
sensor  output  is  more  useful  for  making  time  critical  decisions. 

Voice  communication  is  shown  as  the  only  real  time  information  link  used  by  the  pilot  to 
exchange  information  with  other  vessels.  The  use  of  voice  communications  has  been  a 
significant  contributor  to  improved  safety.  However,  it  sometimes  becomes  difficult  to 
establish  and  maintain  good  communications  as  the  activity  of  the  waterway  increases. 
Organizing  communications  usage  is  one  contribution  made  by  a  VTS  to  improved 
waterways  management. 


Figure  2  -  Traditional  marine  navigation  model  augmented  with  VTS  information 

Model  2  -  There  are  geographic  areas  where  local  conditions  can  complicate  the 
traditional  marine  navigation  process.  A  method,  that  has  proved  to  be  successful  in 
recovering  or  improving  performance,  is  a  vessel  traffic  service.  The  vessel  traffic 
service  is  staffed  with  operators  familiar  with  the  problems  facing  pilots  navigating 
specific  geographic  areas.  Using  shore  facilities,  such  as  radar,  video  cameras. 
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hydrographic  instruments,  meteorological  sensors,  transponders,  etc.,  the  VTS 
operator  is  able  to  create,  update,  and  maintain  current  information  about  a  particular 
section  of  waterway.  This  is  known  as  a  vessel  traffic  service  area  (VISA).  In  modern 
VTS  systems,  this  information  is  maintained  in  a  database  located  in  a  single  computer. 
Larger  VTS  areas  are  subdivided  into  several  VTSAs  based  on  the  amount  of 
information  one  VTS  operator  can  reasonably  manage.  In  a  modern  VTS,  VTSA 
information  is  exchanged  with  the  vessel  pilots  using  voice  communications.  A  diagram 
of  this  augmentation  is  shown  in  Figure  2. 

Like  the  pilot,  the  VTS  operator  performance  can  be  improved  by  improving  the  sensors 
acquiring  information  for  the  VTS  database.  Sensors,  such  as  transponders,  can 
automatically  report  ship  position  and  velocity  information.  Research  conducted  by  the 
USCG  R&D  Center  (Johnson  et  al.,  1995  and  1996)  shows  that  shipboard 
transponders,  such  as  those  use  in  the  Valdez,  Alaska  VTS,  are  very  effective  for 
monitoring  vessels.  As  new  technologies,  such  as  transponders,  are  added  to  VTS 
operations,  the  voice  communications  link  becomes  the  limiting  factor  in  moving 
information  from  the  VTS  database  to  the  ship. 


Figure  3  -  Modern  marine  navigation  with  electronic  navigation  tools  but  without  VTS  information 

Model  3  -  The  improvement  of  shipboard  sensors,  in  particular,  the  introduction  of 
Differential  Global  Positioning  System  (DGPS)  technology  and  the  creation  of 
electronic  chart  replacements  for  the  paper  chart,  is  making  it  possible  to  automate  the 
bulk  of  the  “plotting  process”  shown  in  Figure  1.  Figure  3  depicts  the  impact  that 
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electronic  chart  systems  (ECS),  and  integrated  navigation  systems  are  and  will 
continue  to  have  on  piloting.  The  introduction  of  these  electronic  tools  has  significantly 
decreased  the  amount  of  time  it  takes  to  give  the  pilot  a  graphical  presentation  of  the 
shipboard  sensor  data.  In  fact,  it  is  no  longer  necessary  for  the  pilot  to  visit  each 
sensor’s  display.  All  of  the  sensor  information  can  be  gathered,  organized,  and 
presented  on  a  single  display. 

The  automated  presentation  of  information  has  also  allowed  the  industry  to  improve  the 
efficiency  and  effectiveness  of  the  interface  with  the  ship’s  pilot,  and  to  offer  new 
“navigation”  features.  Features,  such  as  grounding  warnings,  can  now  be  routinely 
provided  when  previously  they  were  computationally  prohibitive  using  traditional  tools 
such  as  paper  charts. 


Figure  4  -  Modem  marine  navigation  with  electronic  navigation  tools  augmented  with  voiceless  VTS  information 


Model  4,  Voiceless  VTS  -  Vyith  the  introduction  of  computer-based  navigation  tools 
aboard  every  ship,  it  becomes  reasonable  to  expect,  that  some  time  in  the  future  these 
systems  would  accept  and  present  information  provided  by  a  VTS.  The  use  of  voice 
communications  between  the  VTS  operator  and  the  pilot  would  be  the  least  desirable 
form  of  such  a  connection.  The  creation  of  a  direct  digital  data  path  from  the  VTS 
database  to  the  electronic  navigation  tools  of  the  navigation  process  can  be 
accomplished  using  either  digital  communications  or  an  area  broadcast.  Wireless 
digital  communications  technology  can  be  used  to  access  the  database  using  TCP/IP 


8 


internet-like  solutions.  At  the  present  time,  the  telecommunications  industry  is 
investing  heavily  in  wireless  digital  communications  development.  For  this  reason,  the 
communications  approach  is  not  the  primary  subject  of  this  report.  This  report 
concentrates  on  the  concept  of  area  broadcasting. 

The  linkage  of  the  VTS  database  with  the  shipboard  systems,  represented  by  the 
electronic  chart  system,  is  shown  in  F/gt/re  4.  By  automating  the  exchange  of 
navigation  information,  the  need  for  voice  communications  between  the  VTS  operator 
and  pilots  should  be  reduced.  This  should  significantly  reduce  the  VTS  operators 
communication  responsibilities  and  allow  more  time  for  acquiring  and  validating 
information  in  the  VTS  database.  It  may  also  be  possible  to  increase  the  size  of  a  VTS 
operators  VTSA  thus  reducing  the  total  number  of  operators  needed  for  a  given 
waterway. 

Voiceless  VTS  would  provide  the  bulk  of  real  time  VTS  information  using  digital 
broadcasting.  This  is  indicated  in  Figure  4  by  the  use  of  a  heavier  arrow.  Besides 
being  the  least  expensive  approach,  reception  of  digital  broadcasts  is  also  the  simplest 
wireless  method  to  incorporate  into  the  navigation  tools.  It  would  be  possible  for 
inexpensive  electronic  chart  systems  to  directly  accept  this  type  of  information  flow. 
While  wireless  digital  communication  is  expected  to  be  commonly  available,  it  will  be 
more  complex  to  implement  and  more  costly  to  use  than  a  digital  broadcast.  Voiceless 
VTS  would  use  digital  communications  for  high  speed  or  special  data  transfer 
capabilities  as  they  are  needed.  Also,  when  inexpensive  service  and  guaranteed 
access  can  be  provided  by  digital  communications,  that  option  can  be  considered  as  an 
alternative  to  digital  broadcasting. 

Summary  -  A  number  of  benefits  would  be  realized  with  the  deployment  of  voiceless 
VTS.  First,  the  digital  broadcasts  would  gradually  become  the  primary  source  of  VTS 
informatiorl.  This  would  significantly  reduce  the  amount  of  voice  communications 
between  pilots  and  the  VTS  operator.  Second,  the  workload  of  the  VTS  operator  would 
be  reduced.  Third,  the  quality  of  the  VTS  information  would  improve  and  the  increased 
capacity  would  allow  more  types  of  information  to  be  provided.  Fourth,  the  VTS 
information  would  go  automatically  to  the  ship’s  computer  systems  and  be  immediately 
available  for  custom  processing.  Fifth,  the  ship’s  pilot  would  have  immediate  access  to 
timely  VTS  information  without  the  burden  of  requesting  and  handling  the  same 
information  using  voice  communications.  Finally,  automated  VTS  technology  may  be 
viewed  as  an  enhanced  port  facility. 

2.2  Voiceless  VTS  -  Database  Issues 

Automating  the  VTS  database  distribution  using  either  the  communication  or  broadcast 
approach  should  reduce  the  existing  communications  workload  of  the  VTS  operator 
and  the  pilot.  However,  voiceless  VTS  could  shift  some  of  the  other  VTS  operator 
responsibilities  onto  the  pilot.  The  net  change  in  the  pilot’s  workload  is  not  clear  and 
the  full  impact  of  the  shift  needs  to  be  investigated  further. 
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The  voiceless  VTS  concept  is  based  on  the  assumption  that  automatic  distribution  of 
the  VTS  database,  or  selected  portions  of  it,  improves  port  safety  and  efficiency  from 
the  navigation  perspective.  One  cost  of  this  navigation  benefit  may  be  the  compromise 
of  overall  port  security.  The  present  manual  method  used  to  distribute  VTS 
information,  model  2,  does  limit  outside  access  to  the  information  contained  in  the 
database.  The  VTS  operator  is  able  to  use  experience,  local  instructions,  and 
judgment  to  decide  when  and  what  information  goes  out  over  the  airwaves.  It  needs  to 
be  recognized  that  easy  access  to  VTS  database  information  could  compromise  the 
existing  level  of  overall  port  security. 

Recognizing  the  potential  for  security  problems,  some  precautions  can  be  taken.  The 
design  of  the  broadcast  format  can  provide  for  encryption  that  can  be  used  to  limit 
access  to  the  content  of  the  broadcast.  In  addition  to  coding  the  broadcast,  the 
broadcast  content  should  be  selected  to  minimize  the  amount  of  compromising 
information  that  is  broadcast.  The  accuracy  of  the  information  contained  in  the 
broadcast  is  also  an  important  system  design  and  operational  issue.  That  is;  should 
highly  accurate  port  information  be  intentionally  “dithered”  for  security  reasons?  This  is 
similar  to  the  selective  availability  added  to  the  GPS  signal.  Similar  information  access 
issues  also  exist  for  the  distribution  of  information  using  communications  methods. 
Access  to  the  VTS  database  will  have  to  be  controlled  in  order  to  maintain  port  security. 

Another  concern  is  the  validity  of  the  database.  The  voiceless  VTS  model.  Figure  4, 
indicates  that  the  information  flows  to  the  navigation  process  from  the  VTS  maintained 
database.  The  information  contained  in  the  database  is  created  using  a  number  of 
sensors.  The  specific  sensors  and  how  the  information  is  entered  into  the  database  is 
determined  by  the  design  and  operation  of  a  particular  VTS.  The  VTS  assumes  some 
responsibility  for  the  validity  and  accuracy  of  the  database.  Because  of  this 
responsibility,  the  database  information  that  is  distributed  should  be  based  on  sensor 
information  that  can  be  validated  using  various  cross  checking  mechanisms.  This 
validation  is  necessary  to  protect  the  mandatory  participant’s  navigation  processes 
from  false  information  that  could  enter  the  database  due  to  equipment  malfunctions  or 
from  sources  intending  to  corrupt  the  data  base.  This  validation  of  information  is  a 
significant  security  improvement  over  proposals  to  use  single  sensor  systems  such  as 
the  public  use  of  ship-to-ship  transponders. 

Automating  the  distribution  of  information  is  going  to  speed  up  a  process  that  is  now 
limited  by  two  people  talking  to  each  other  over  a  radio.  This  is  a  public  conversation 
that  both  people  know  can  be  received  by  anyone  in  the  area.  While  voice  radio  may 
not  be  the  most  efficient  method  to  exchange  information  from  a  navigation  perspective, 
it  does  possess  some  characteristics  that  make  people  careful  and  sensitive  to 
protecting  the  security  of  the  port.  These  characteristics  need  to  be  recognized  and 
integrated  into  the  voiceless  VTS  design  details. 

2.3  Voiceless  VTS  -  Digital  Broadcasting  Issues 

Digital  broadcasting  is  a  one  way  flow  of  information,  similar  to  radio  or  television 
broadcasting,  using  public  frequencies.  Direct  digital  communications  is  the  use  of  a 
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two  way  channel,  usually  through  a  commercial  service  provider,  to  exchange 
information  between  two  specific  facilities.  Two  significant  factors  that  favor  digital 
broadcasting  over  direct  digital  communications  for  the  distribution  of  VTS  information 
are  the  costs  to  the  user  and  the  potential  for  unlimited  and  simultaneous  distribution. 
Historically,  navigation  signals  have  been  provided  free  of  charge  in  the  United  States. 
This  policy  has  resulted  in  widespread  use  of  navigation  signals  by  the  general  public. 
This  has  created  a  strong  competitive  market  for  consumer  navigation  electronics,  and 
this  in  turn  has  supported  the  government’s  general  desire  to  create  a  safe  recreational 
and  commercial  marine  environment.  This  has  not  been  true  in  countries  that  charge 
for  the  use  of  navigation  signals.  If  it  satisfies  their  information  needs,  consumers 
generally  favor  public  and  free  broadcasts.  They  view  their  primary  cost  for  the 
information  as  the  one-time  purchase  price  of  the  receiver,  and  they  appreciate 
avoiding  the  need  for  licensed  radio  equipment  or  the  payment  of  usage  fees. 

Voiceless  VTS  information  can  be  distributed  using  communications  links  as  long  as 
the  communications  capacity  can  expand  to  serve  demand.  As  usage  grows,  providing 
timely  access  to  all  users  becomes  a  communications  capacity  problem.  This  problem 
is  similar  to  that  being  experienced  by  popular  web  sites  on  the  Internet,  today.  Timely 
access  to  VTS  information  is  very  important.  If  it  cannot  be  accessed  quickly,  it  is  of  no 
use  for  navigation.  Members  of  the  marine  community  cannot  be  put  in  a  position 
where  they  are  competing  with  each  other  to  access  the  information  they  all  need. 

A  voiceless  VTS  broadcast  supports  the  historic  concept  that  the  primary  responsibility 
for  the  safe  navigation  of  vessels  rests  with  the  vessel  masters.  Providing  timely, 
accurate,  and  relevant  navigation  information  simultaneously  to  all  vessels  will  ensure 
that  the  independent  navigation  decisions  of  vessel  pilots  are  based  on  common 
information.  The  vision  of  voiceless  VTS  digital  broadcasting  that  this  report 
represents  is  intended  to  be  compatible  with  this  idea.  The  following  are  overall  design 
guidelines  for  this  digital  broadcast  system: 

Information  will  be  simultaneously  provided  to  assist  all  vessels  navigating  the 
VTS  coverage  area. 

The  information  will  be  broadcast  in  discrete  messages. 

Each  message  will  be  identified  in  such  a  way  that  reception  equipment  will  be 
able  to  identify  the  message  by  type  and  accept  or  ignore  it  as  appropriate. 
Equipment  will  be  designed  to  hold  information  until  it  has  been  superseded. 
Messages  will  be  encoded  with  ©rror-detecting/forward  error-correcting  codes  to 
guarantee  shipboard  systems  either  reject  or  correct  corrupted  information 
before  use. 

The  manner  in  which  navigation  safety  information  is  displayed  or  otherwise 
utilized  will  be  a  function  of  different  shipboard  systems. 

Broadcasting  does  not  provide  for  any  acknowledgment  that  what  is  being  sent  is  being 
properly  received.  Information  in  digital  broadcasts  must  be  packaged  and  scheduled 
with  the  understanding  that  portions  of  the  contents  may  never  reach  the  user. 

Although  broadcasting  does  not  provide  directly  for  interactive  error  correction  with 
each  user,  there  are  methods  that  can  provide  for  some  error  reduction.  These  are 
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discussed  later  in  the  report.  As  long  as  users  and  providers  can  accept  some  lost 
information  from  the  broadcast,  digital  broadcasting  has  been  found  to  be  a  cost 
effective  method  for  distributing  information. 

If  there  is  concern  about  the  reliability  of  broadcast  signals,  recall  that  essentially  all 
radionavigation  systems  are  themselves  based  on  signal  broadcasting.  A  unique 
practical  example  that  combines  broadcasting  with  computer  based  technology  is  the 
USCG  implementation  of  the  Differential  Global  Positioning  System  (DGPS)  service. 
The  success  of  this  service  operationally  demonstrates  that  the  automated  creation  and 
automatic  distribution  of  digital  information  can  safely  and  successfully  improve  the 
performance  of  shipboard  navigation  even  without  the  benefit  of  interactive  error 
correction. 

2.4  Open  System  Interconnection  7-Layer  Model 

This  report  discusses  the  concept  of  broadcasting  VTS  navigation  information  by  using 
a  model  developed  by  the  International  Standards  Organization  HSOV  The  model  is 
called  the  Open  Systems  Interconnection  Reference  Model  (OSI  model,  for  short).  It 
was  developed  to  provide  a  general  structure  for  understanding  and  assisting  in  the 
development  of  digital  links  between  computer  based  systems.  This  general  structure 
was  developed  to  help  engineers  create  internationally  standardized  systems  that  use 
a  number  of  different  data  and  communication  protocols.  The  OSI  model  is  used  in  this 
report  to  help  identify,  define,  and  describe  features  that  a  digital  broadcast  service 
must  posses.  While  designed  primarily  for  communications  systems,  the  OSI  model 
was  found  to  be  satisfactory  as  an  organizing  framework  for  digital  broadcasting. 

The  OSI  model  partitions  the  digital  computer  communications  process  into  seven 
layers  of  services.  The  seven  layers  interconnect  to  provide  the  functions  needed  to 
move  digital  information.  Each  layer  provides  a  service  that  ensures  that  digital 
information  is  transferred  correctly.  Standards  and  methods  can  be  defined  for  each 
layer.  Because  broadcasting  systems  do  not  use  a  bi-directional  communications  path, 
the  full  features  of  each  layer  cannot  be  utilized.  However,  some  methods  can  be 
introduced  at  the  system  level  that  could  compensate  for  the  lack  of  bi-directional  layer 
connections. 

The  top  three  layers  of  the  model  are  used  to  describe  the  process  of  exchanging 
information  and  the  support  functions  needed.  The  bottom  four  layers  of  the  model 
describe  the  processes  needed  to  connect  two  systems  and  control  information  flow 
without  errors,  loss  of  information,  or  duplication  of  information.  The  following  briefly 
describes  the  services  provided  by  each  layer  in  the  OSI  model.  Figure  5. 

Application  Laver:  This  layer  interfaces  directly  to,  and  performs  common  application 
services  for,  the  application  processes.  It  directly  supports  the  exchange  of  information 
between  application  programs  at  both  ends  of  the  data  path.  This  layer  is  not  part  of 
the  applications  that  either  generate  or  use  the  information.  Specific  applications  are 
external  to  the  OSI  model. 
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Presentation  Laver:  Provides  the  process  to  transform  information  into  a  mutually 
agreed  format.  It  relieves  the  Application  Layer  of  concern  regarding  syntactical 
differences  in  data  representation  between  the  two  “end-user”  applications. 

Session  Laver:  Responsible  for  managing  the  connection  between  cooperating 
applications.  It  manages  such  things  as  link  termination  and  restart  procedures. 

Transport  Laver:  Manages  the  connection  between  the  two  end  nodes  in  the 
information  exchange.  It  provides  the  transparent  transfer  of  information  between  the 
two  “end-user”  applications,  thus  relieving  the  upper  layers  from  any  concern  with 
providing  reliable  and  cost-effective  data  transfer. 

Network  Laver:  Responsible  for  providing  the  functional  and  procedural  means  of 
transferring  variable  length  data  sequences  from  a  source  to  a  destination.  It  performs 
routing,  flow  control,  and  segmentation/de-segmentation  functions. 

Data  Link  Laver:  Provides  the  reliable  transfer  of  data  frames  over  the  physical  layer. 

It  can  be  used  to  detect  and  correct  some  of  the  errors  that  occur  in  the  Physical  Layer. 
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Figure  5  -  General  OSI  model  stack 


Physical  Laver:  Responsible  for  the  mechanical,  electrical,  functional,  and  procedural 
aspects  of  the  data  link  between  the  “end-users”.  It  establishes  and  terminates  the 
communication  medium  connection,  manages  contention  resolution  and  flow  control, 
and  converts  the  representation  of  digital  data  in  the  user  equipment  and  the 
corresponding  signals  transmitted  over  the  communications  medium. 

The  details  of  the  physical  layer  design  are  driven  by  the  characteristics  of  the 
communications  medium.  In  wireless  broadcasting  the  communications  medium 
characteristics  are  a  significant  factor  in  determining  the  overall  design.  In  this  report 
the  communications  medium  is  discussed  as  an  “eighth  layer”  in  order  to  draw  attention 
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to  signal  propagation  and  electronic  interference  issues.  In  this  report  the  eighth  layer 
will  be  referred  to  as  the  “Propagation  Layer”. 

Propagation  Laver:  This  layer  provides  the  connection  between  the  information  source 
and  the  destination.  The  uncontrolled  characteristics  of  the  propagation  layer  have  a 
significant  impact  on  the  design  and  operation  of  the  layers  above  it  and  performance 
of  the  overall  system.  Many  of  the  precautions  taken  in  higher  layers  are  designed  to 
combat  problems  that  exist  in  this  layer. 

Each  layer  communicates  with  the  layers  above  and  below  it.  Figure  5  shows  how 
these  layers  can  be  organized  into  “stacks.”  Note  that  each  layer  exists  at  both  the 
broadcast  and  reception  side.  Each  layer  in  the  reception  stack  must  be  designed  with 
the  detailed  knowledge  of  what  the  corresponding  layer  in  the  broadcast  stack  is  doing 
to  the  information  passing  through  that  layer.  It  is  the  detail  of  this  type  of  information 
that  makes  it  necessary  to  use  clearly  agreed  upon  methods  and  standards  to 
implement  a  broadcast  service.  It  is  also  important  to  keep  in  mind  that  an  unlimited 
number  of  broadcast  reception  stacks  can  be  simultaneously  receiving  the  signal 
produced  by  a  single  broadcast  stack. 

The  layers  on  the  broadcast  side  may  attach  headers  to  the  messages  as  they  process 
them  and  pass  them  on  to  the  next  lower  layers.  Each  lower  layer  treats  the  headers 
from  the  levels  above  it  as  part  of  the  data  that  it  is  forwarding.  On  the  receiver  side, 
as  a  report  is  passed  to  successively  higher  layers,  each  layer  examines  the  header 
applied  at  the  corresponding  level  on  the  transmitter  side  to  determine  how  the 
particular  group  of  data  is  to  be  processed  and  routed  and  then  removes  that  header 
before  passing  the  data  on  to  the  next  higher  level. 
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3.0  Sample  Design  -  VTS  Navigation  Safety  Broadcast 

In  a  vessel  traffic  service,  such  as  the  USCG  VTS  in  New  York,  real  time  information  is 
gathered  using  a  variety  of  sensor  technologies:  radar,  video  cameras,  voice  radio 
reports,  and.  more  recently,  digital  radio  transponders.  The  information  is  entered  into 
a  common  database.  The  database  information  is  presented  to  a  VTS  operator  using 
one  of  several  display  consoles.  The  VTS  operator  first  “sees”  the  information  on  a 
console  and  then  provides  the  information  to  marine  pilots  using  VHF  voice 
communications. 

All  of  the  information  that  is  contained  in  the  New  York  VTS  computer  system.  Joint 
Maritime  Command  Information  System  (JMCIS).  is  organized  and  maintained  in  a 
common  database.  JMCIS  already  allows  each  operator’s  console  at  the  VTS  to 
independently  display  information  stored  in  the  database.  The  console  information, 
and  the  way  it  is  presented,  is  independent  from  the  other  operator  consoles  and  the 
database  itself.  The  existing  capabilities  of  JMCIS  imply  that  it  would  not  be  difficult  to 
create  a  process  that  could  provide  the  information  needed  for  a  VTS  navigation  safety 
broadcast  without  interfering  with  normal  VTS  operations.  The  simple  design  of  a  VTS 
navigation  safety  broadcast  presented  in  this  section  assumes  that  such  a  capability 
can  be  created. 

This  section  presents  the  technical  details  and  issues  surrounding  implementation  of 
the  line  in  Figure  4,  “Digital  Broadcasting.”  that  connects  the  “VTS  Database”  and 
“Electronic  Chart  System”  blocks.  This  service  of  the  VTS  is  referred  to  as  a  “VTS 
navigation  safety  broadcast  (NSB)”  in  this  report  to  distinguish  it  from  some  general 
digital  broadcast.  It  is  not  the  intent  of  this  report  to  propose  a  specific  broadcast 
design  or  a  set  of  VTS  broadcast  services.  However,  this  report  does  provide  the 
background  understanding  needed  to  define  a  broadcast  service.  A  definition  of  the 
broadcast  service  is  needed  to  support  the  development  of  a  broadcast  performance 
standard  and  the  creation  or  identification  of  the  supporting  technical  standards  and 
methods.  Investigation  of  the  issues  that  are  raised  by  the  performance  standard 
requirements  will  be  needed  before  implementation  recommendations  can  be  made.  In 
this  section  a  model  of  a  broadcast  system  is  suggested  and  then  used  to  discuss  the 
technical  issues  that  should  be  considered  while  creating  the  performance  standard. 

The  assumptions  that  have  been  implicitly  made  in  selecting  the  range  of  options  to  be 
discussed  are: 

The  system  makes  information  available,  but  does  not  require  message-by¬ 
message  confirmation  of  receipt. 

The  information  distributed  must  be  made  available  to  vessels  in  such  a  way  that 
the  marine  pilot  or  master  begins  to  obtain  it  before  entering  the  VTS  vessel 
traffic  service  area.  This  implies  that  for  ports  approached  from  the  open  sea. 
the  broadcasts  must  be  received  some  distance  offshore. 

The  content  of  the  messages  will  change  at  varying  rates.  Some  information 
may  not  change  during  the  entire  period  of  the  port  call  of  a  vessel  (e.g.. 
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announcements  of  some  uncharted  hazards  to  navigation),  but  would  have  to  be 
broadcast  frequently  enough  to  make  certain  that  arriving  vessels  receive  it  as 
they  approach.  At  the  other  extreme,  there  may  be  information  routinely  updated 
at  rates  on  the  order  of  once  per  minute. 

The  content  of  the  broadcast  will  be  used  for  a  variety  of  purposes. 

Many,  if  not  most,  of  the  services  will  be  provided  by  messages  that  are  in 
totality  quite  short  (equivalent  to  something  on  the  order  of  100  characters  of 
text  or  less). 

The  remainder  of  this  report  describes  the  details  of  a  VTS  navigation  safety  broadcast 
design.  A  simple  model  of  a  VTS  navigation  safety  broadcast  is  described  and  used  to 
separate  the  broadcast  details  from  standard  communications  details.  The  broadcast 
details  are  further  discussed  from  the  information  flow  perspective  using  the  OS  I  model, 
and  by  introducing  possible  broadcast  processes  and  system  design  techniques.  The 
result  of  the  investigation  created  a  list  of  tasks  that  will  need  to  be  addressed  during 
development  of  a  performance  standard  and  as  a  guide  in  assembling  an  actual 
system. 

3.1  General  Concept  of  the  VTS  Navigation  Safety  Broadcast 

In  point-to-point  communications,  the  objective  is  to  move  information  without  error 
between  two  systems  using  a  bi-directional  communication  channel.  The  processes  at 
each  end  of  the  communications  channel  interact  to  eliminate  any  errors  introduced  by 
the  connection.  However,  broadcasting  is  done  without  a  specific  recipient.  An 
interactive  dialog  is  not  possible. 

It  is  better  to  think  of  broadcasting  as  two  processes  that  have  separate  objectives;  one 
for  the  transmitter  and  a  second  for  the  receiver.  First,  the  broadcast  transmitter’s 
objective  is  to  make  information  available  in  a  geographic  area.  This  would  be  the 
primary  objective  of  a  VTS  broadcast.  Second,  the  user’s  receiver  objective  is  to 
intercept  the  information  available  in  a  given  area.  From  the  users’  perspective,  it  may 
be  necessary  to  support  simultaneous  reception  of  several  broadcasts.  This  is  due  to 
the  fact  that  the  user’s  area  of  interest  may  overlap  several  broadcast  coverage  areas. 
The  distinctions  of  these  two  views  are  important  when  the  details  of  the  design 
alternatives  are  being  considered.  It  is  key  to  understanding  why  designing  a  reliable 
digital  broadcasting  system  is  different  from  designing  a  communications  system.  The 
following  is  a  simple  model  of  a  broadcast  system. 

3.1.1  Simple  Model  of  a  Broadcast  System 

A  random  coastline  is  depicted  on  the  right  side  of  Figure  6.  The  coastal  area  is 
divided  into  two  independent  vessel  traffic  service  areas  (VTS-1  VTSA  and  VTS-2 
VTSA).  A  practical  example  of  this  would  be  the  separate  US  and  Canadian  VTS 
systems  in  the  Puget  Sound  area.  Four  digital  broadcast  sites  (A,  B,  C,  and  D)  are 
shown  along  the  coastline.  The  radio  coverage  of  each  is  represented  by  circles  drawn 
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sround  sach  broadcast  sita.  Notica  that  tha  covaraga  araa  of  broadcast  B  and  C 
cloarly  cross  tha  boundary  batwaan  tha  two  VTS  araas .  This  bagins  to  suggast  that 
VTS  broadcasts  should  ba  dasignad  to  provida  information  dastinad  for  a  particular 
araa  indapandantly  of  which  VTS  might  provida  tha  Information!  A  vassal  (V-1)  is 
indicatad  on  tha  diagram  to  raprasant  a  typical  usar  of  tha  broadcast  information.  Not 
shown  in  tha  diagram  ara  all  tha  shora  facilitias  associatad  with  tha  VTS  systams. 

Thay  ara  simply  assumad  to  axist  and  ara  contributing  thair  information  to  ona  or  tha 
othar  VTS  databasa. 

Tha  laft  sida  of  Figure  6  is  a  datailad  diagram  of  tha  “Digital  Broadcasting”  lina  that 
connacts  tha  “VTS  Databasa”  and  “Elactronic  Chart  Systam”  blocks  of  Figure  4.  It 
diagrams  tha  flow  of  information  from  aach  databasa  to  tha  usar  (V-1 ).  Tha  information 
availabla  to  tha  usar  dapands  on  whara  tha  usar  is  locatad  and  tha  broadcast  strategy 
of  aach  broadcast  scheduler  (see  section  3.3.1). 


Figure  6  -  Sample  model  of  voiceless  VTS  Navigation  Safety  Broadcast  system 

The  data  to  be  broadcast  is  independently  selected  from  each  database  by  a  “VTS 
database  search”  process.  This  database  search  process  sends  the  selected  data  to 
the  “broadcast  site  router”  (line  between  the  “database”  box  and  “site  router”  box).  This 
is  done  using  standard  communications  methods.  The  broadcast  site  router  “knows” 
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the  coverage  characteristics  of  each  broadcast  site.  The  router  actually  uses  the 
database  information  to  decide  which  broadcast  sites  should  receive  the  information. 
Considering  data  characteristics,  such  as  geographic  location,  the  router  separately 
sends  the  information  to  the  “broadcast  scheduler”  process  at  each  broadcast  site 
responsible  for  transmitting  the  information  to  the  different  coverage  areas.  Again,  this 
is  done  using  standard  communications  methods.  The  broadcast  scheduler  process  is 
the  horizontal  rectangle  connecting  the  two  sides  of  the  OSI-stack.  Notice  that  in  this 
simple  model,  data  from  the  VTS-1  database  is  sent  to  sites  A,  B,  and  C,  and  that  data 
from  the  VTS-2  database  is  sent  to  sites  B,  C,  and  D.  The  broadcast  scheduler 
process  at  each  broadcast  site  independently  accepts  the  VTS  information  from  the 
router,  maintains  a  local  database,  and  schedules  information  for  broadcast  based  on 
its  local  configuration  information.  In  this  example,  it  is  the  scheduler  process  that 
decides  what  and  when  information  is  broadcast.  The  output  of  the  scheduler  is  “the 
broadcast”  (also  see  section  3.3.1). 

The  vessel  (V-1 )  is  able  to  receive  the  signals  from  the  “B”  and  “C”  transmitter  sites. 
Although  both  B  and  C  were  provided  the  same  information  from  both  VTS  databases, 
the  actual  information  transmitted  will  depend  on  the  independent  broadcast  scheduler 
at  each  site.  For  example,  the  B-transmission  scheduler  may  emphasize  VTS-I  VTSA 
information  and  the  C-transmission  scheduler  may  emphasize  VTS-2  VTSA 
information. 

The  purpose  of  this  model  is  to  expose  the  portion  of  the  overall  system  design 
requiring  digital  broadcast  standards,  methods,  and  technology  development.  The 
communication  links  between  the  VTS  database  search  and  the  broadcast  site  router 
processes:  and  between  the  broadcast  site  router  and  the  broadcast  scheduler 
processes  use  some  form  of  standard  OSI  model  communications  stack.  While 
development  of  these  processes  is  needed  for  a  VTS  broadcast,  the  development  of 
the  communications  interfaces  between  them  is  not.  Standards  and  methods  already 
exist.  The  remainder  of  this  report  will  focus  primarily  on  the  OSI  model  stacks  that 
connect  the  broadcast  scheduler  and  the  “user”  application. 

The  full  design  of  a  broadcast  system  will  include  a  number  of  OSI  model  “stacks”. 

Most,  if  not  all,  of  these  stacks  will  describe  the  point-to-point  communication  of 
information  and  control  signals  between  the  computer  systems  needed  to  create  the 
broadcast  service.  For  example,  in  an  actual  system  the  broadcast  scheduler  most 
likely  will  not  be  located  within  the  same  computer  that  controls  the  signal  of  the 
broadcast  transmitter.  However,  in  order  to  keep  the  digital  broadcasting  issues  clearly 
exposed,  it  is  assumed  that  the  broadcast  scheduler  and  all  the  OSI  model  broadcast 
layers  exist  in  the  same  piece  of  equipment.  For  similar  reasons,  the  shipboard 
equipment  assumes  the  radio  antenna  and  computer  display  is  the  same  equipment 
(although,  admittedly,  this  is  an  even  more  remote  possibility  in  an  actual  shipboard 
system).  The  following  discussion  of  digital  broadcasting,  that  is  the  link  between  the 
broadcast  site  and  the  ship,  is  based  on  the  OSI  model  shown  in  Figure  7. 
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3.1.2  OSI  Link  between  Broadcast  Site  and  Vessels 

The  various  processing  steps  needed  to  implement  the  transfer  of  information  are 
distributed  throughout  the  layers  in  the  OSI  model.  The  OSI  model  is  not  rigid  in 
design.  In  fact,  there  can  be  “sub-layers”  with  greater  processing  responsibilities  than 
some  layers.  In  order  to  apply  the  OSI  model  to  a  specific  design  it  is  necessary  to 
have  a  general  understanding  of  what  the  design  does.  The  significance  of  a  layer  to  a 
particular  communications  problem  depends  on  what  is  being  attempted.  Figure  1 
diagrams  the  processing  layers  that  the  broadcast  information  must  flow  through  in 
order  to  move  from  the  broadcast  scheduler  database  to  a  shipboard  application. 

A  continuous  stream  of  messages  containing  VTS  navigation  information  is  created  by 
the  broadcast  scheduler.  Each  of  the  OSI  model  layers  then  processes  this  message 
stream  beginning  with  the  application  layer,  “seven”,  down  to  the  physical  layer,  “one”. 
It  is  the  physical  layer  process  that  actually  transmits  the  information  as  a  radio  signal. 


Figure  7  -  OSI  model  for  link  between  broadcast  site  and  vessels 


As  mentioned  earlier,  transmitting  the  signal  is  the  final  objective  of  the  VTS  Navigation 
Safety  Broadcast  service.  At  any  given  time,  an  unknown  number  of  users  are 
receiving  the  signal.  Of  those  messages  broadcast,  it  is  difficult  (but  not  impossible)  to 
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know  the  number  of  messages  that  are  not  being  correctly  received  due  to  propagation, 
electromagnetic  interference,  or  equipment  problems. 

Reception  and  use  of  the  broadcast  message  are  represented  by  the  stack  of  layers  on 
the  right  of  Figure  7.  Reception  begins  at  the  physical  layer.  Each  layer  from  one 
through  seven  processes  the  received  signal  until  the  “original”  message  is  presented 
to  the  shipboard  application.  There  are  several  points  to  remember; 

Each  layer  in  the  reception  stack  compliments  the  process  of  the  same  layer  in 
the  broadcast  stack. 

While  the  reception  layers  used  aboard  all  ships  perform  the  same  processes, 
the  computer  algorithms  for  those  layers  may  not  be  identical  in  ail  equipment. 
The  shipboard  application  may  receive  less  information  than  a  single  broadcast 
transmits  due  to  uncorrectable  propagation  errors. 

The  shipboard  application  may  receive  more  information  than  a  single  broadcast 
transmits  due  the  simultaneous  reception  of  a  number  of  broadcasts. 

The  computer  representation  of  the  message  data  passed  to  the  shipboard 
application  may  not  match  what  it  was  when  produced  by  the  broadcast 
scheduler.  This  may  be  due  to  reception  equipment  design  details. 

The  network  communication’s  stack  on  the  left  side  of  Figure  7  is  simply  a  reminder  that 
the  broadcast  site  must  be  connected  to  the  VTS  network.  The  “Broadcast  Scheduler” 
obtains  navigation  related  information  from  the  VTS  database  using  point-to-point 
communications  methods. 

Based  upon  an  analysis  of  the  link  between  the  broadcast  scheduler  and  the  user 
application  using  the  OSI  model  layer  definitions  and  implementation  guidelines,  a  list 
was  produced  that  describes  the  processing  steps  needed  to  implement  a  Navigation 
Safety  Broadcast  (NSB).  Each  of  the  processing  steps  is  associated  with  a  layer  in  the 
OSI  model.  Although  it  may  not  be  necessary  to  incorporate  some  of  these  steps  in  the 
final  design,  it  will  be  necessary  to  evaluate  them  during  the  research  program.  The 
following  steps  should  be  performed  in  the  order  they  are  presented. 

Broadcast  Site  Information  Processing  Steps  bv  OSI  Laver: 

Layer  7  -  Organize  the  information  to  be  broadcast  into  standard  message  structures. 
Layer  6  -  First,  convert  the  contents  of  the  messages  into  the  standard  symbol  codes. 
Second,  reduce  the  size  of  the  coded  messages  using  an  agreed  upon 
standard  compression  algorithm.  Third,  encrypt  the  messages  as  required  to 
protect  the  information. 

Layer  5  -  Provide  unencrypted  information  about  the  broadcast  service. 

Layer  4-  First,  break  the  encrypted  compressed  coded  messages  into  fixed  length 
packets  for  broadcast.  Second,  monitor  the  length  of  the  broadcast  queue 
and  provide  queue  length  information  back  to  the  broadcast  scheduling 
process.  The  queue  length  is  an  important  part  of  the  scheduler’s  “timely” 
distribution  strategy.  Third,  maintain  a  separate  temporary  queue  of  recently 
broadcast  packets  for  possible  future  retransmission.  Fourth,  resubmit  past 
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packets  for  broadcast  when  directed  by  the  “broadcast  scheduler”  (see 
section  3.1.3). 

Layer  3  -  No  processing  responsibility.  This  would  change  substantially  if  the 
broadcast  site  transmitted  on  more  than  one  frequency. 

Layer  2  -  Place  the  packets  into  some  form  of  synchronous  or  asynchronous  framing 
structure  that  contains  error  detection  and  forward  error  correction 
mechanisms. 

Layer  1  -  Convert  the  coded  frames  into  the  appropriate  radio  signal  and  transmit  that 
signal  into  the  coverage  area. 

Reception  Site  Information  Processing  Steps  by  OSI  Laver: 

Layer  1  -  Intercept  the  broadcast  signal,  demodulate  the  data  stream  and  recover  bit 
and  frame  synchronization.  Construct  the  information  frames  and  pass  them 
to  the  next  level  for  testing. 

Layer  2  -  Apply  the  standard  error  detection  and  forward  error  correction  mechanisms 
to  test  for  and  correct  errors.  Reconstruct  packets  from  correct  information. 
Throw  away  information  that  cannot  be  reconstructed  into  correct  packets. 
Layer  3  -  Combine  data  packets  received  from  multiple  broadcasts  into  a  single  stream 
of  packets  and  provide  them  to  the  next  layer. 

Layer  4  -  Assemble  the  encrypted  compressed  coded  messages  from  the  received 
packets. 

Layer  5  -  Recognize,  capture,  and  provide  useful  broadcast  service  information  to  the 
layers  below  the  session  layer. 

Layer  6  -  First,  apply  the  decryption  process  to  the  messages.  Second,  if  decryption  is 
successful,  expand  the  messages  using  the  agreed  upon  standard 
decompression  algorithm.  Third,  convert  the  coded  message  for  the 
application  being  serviced. 

Layer  7  -  Convert  the  received  message  into  the  representation  needed  for  the 
application  being  served  and  provide  the  information  to  that  application. 

In  communications  systems,  several  strategies  involving  layers  2,  3,  and  4  can  be  used 
to  implement  error  recovery.  These  methods  can  be  used  because  the  receiving 
system  can  indicate  to  the  sending  system  that  there  is  a  problem  with  the  received 
information.  This  is  done  by  using  the  bi-directional  communications  link  itself.  The 
following  section  suggests  that  there  may  be  a  system  level  method  to  recover  from 
some  reception  errors  in  a  broadcast  system. 

3.1.3  Extended  Model  of  a  Broadcast  System 

The  design  of  an  actual  VTS  navigation  safety  broadcast  system  would  include 
provisions  to  monitor  the  system  performance  and  control  the  system  operation.  While 
this  report  concentrates  on  identifying  the  broadcast-specific  issues  that  need  further 
development,  some  of  the  normal  monitoring  and  control  aspects  of  the  system  can  be 
used  to  improve  the  broadcast  performance.  Because  broadcast  monitoring  could  be 
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used  to  improve  performance,  it  will  be  introduced  into  the  sample  design  and 
discussed. 

The  primary  sources  of  errors  in  wireless  data  links  are  signal  propagation  variations 
and  electronic  interference.  Some  of  these  problems  can  simultaneously  affect  the 
entire  area  covered  by  a  broadcast.  Either  problem  causes  the  received  signal  to  be 
altered  or  temporarily  lost.  Both  problems  are  detected  by  the  error  detection  and 
fon/vard  error  correction  processes  in  OSI  model  reception  layer  2. 

Figure  8  diagrams  an  example  of  two  monitor  sites  (Mon.  1  and  Mon.  2).  The  network 
diagram  on  the  left  indicates  that  the  monitors  could  be  allowed  to  forward  information 
directly  to  the  broadcast  scheduler  processes.  In  addition  to  this  possible  connection, 
the  monitors  would  also  provide  navigation  safety  broadcast  status  to  the  VTS. 


Figure  8  -  Extended  model  of  voiceless  VTS  Navigation  Safety  Broadcast  system 


In  normal  operation,  the  broadcast  packets  are  identified  with  a  sequential  number. 

This  allows  the  receiving  transport  layer  (layer  4)  to  properly  reassemble  the  message 
stream  in  the  correct  order.  When  a  packet  is  damaged,  the  introduced  error  is 
detected  at  the  data  link  layer  and  the  packet  is  not  passed  to  the  transport  layer.  If  the 
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monitor  detects  the  fact  that  an  expected  sequentially  numbered  packet  is  not  received, 
the  monitor  can  notify  the  broadcast  scheduler  that  the  missing  packets  need  to  be 
broadcast  again.  If  detection  and  re-broadcast  can  be  done  quickly,  this  approach 
could  improve  overall  system  throughput  and  reliability.  The  development  and  testing 
of  this  approach  should  be  undertaken  as  part  of  future  digital  broadcast  research. 

The  benefit  of  monitoring  the  navigation  safety  broadcast  is  significant  for  the  VTS.  If 
the  broadcast  is  experiencing  problems  for  whatever  reason,  the  users  will  begin  using 
the  next  alternative.  That  alternative  might  be  VHF  FM  calls  to  the  VTS. 

3.2  Broadcast  System  Processes,  Standards,  and  Methods 


The  purpose  of  this  report  is  not  to  recommend  a  specific  design  for  a  navigation  safety 
broadcast.  However,  processes,  standards,  and  methods  requiring  further  research 
were  identified  during  the  description  of  a  sample  design  in  the  previous  sections.  A 
definition  and  background  discussion  of  each  of  these  processes,  standards,  and 
methods  are  provided  in  this  section.  The  processes,  standards,  and  methods 
identified  in  the  sections  described  above  and  that  require  further  research  or 
identification  are  listed  in  Figure  9. 


1 .  VTS  Database  Search  process. 

2.  Broadcast  Site  Router  process. 

3.  Broadcast  Scheduler  process. 

4.  Broadcast  Monitor  process. 

5.  Internal  system  message  and  command  structure  standard. 

6.  Broadcast  message  structure  standard,  which  includes 

a.  Message  compression  method, 

b.  Message  encryption  method, 

c.  Packetizing  method, 

d.  Error  Detection  and  Forward  Error  Correction  method, 

e.  Packet  framing  structure  method,  and 

f.  Radio  transmission  method  and  frequency  plan. 

7.  Shipboard  Information  Presentation  process. _ 


Figure  9  -  Processes,  Standards,  and  Methods  requiring  research  or  identification 


3.2.1  VTS  Database  Search  Process 

The  sample  broadcast  system  design  (section  3.1)  assumes  that  the  information 
contained  in  the  VTS  broadcast  originates  from  a  valid  VTS  database.  The  VTS 
Database  Search  process  is  installed  in  the  computer  network  containing  the  VTS 
database.  Once  the  search  rules  for  this  process  are  established,  this  process  runs 
independently  of  the  broadcast  system.  The  search  scans  the  database  or  it  intercepts 
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database  updates  as  necessary  to  gather  and  provide  the  types  of  information  it  has 
been  instructed  to  pass  to  the  broadcast  system.  The  information  provided  by  this 
process  is  communicated  to  a  Broadcast  Site  Router  process  using  the  data  structure 
defined  in  the  internal  system  message  and  command  structure  standard. 

Neither  this  search  process  nor  other  elements  of  the  broadcast  system  check  the 
validity  of  information  in  the  database.  It  is  the  responsibility  of  the  VTS  information 
gathering  system  to  provide  validated  information.  This  is  a  critical  operational 
assumption  that  may  require  a  fresh  assessment  of  how  information  is  classified  and 
entered  into  present  VTS  databases. 

This  process  should  be  kept  simple  and  access  to  it  should  be  limited.  A  minimal 
computational  load  should  be  placed  on  a  host  system,  such  as  the  Joint  Maritime 
Command  Information  System  (JMCIS)  used  at  existing  USCG  VTS.  This  process 
should  be  under  the  control  of  the  VTS  operator.  The  security  of  the  VTS  database 
and  the  integrity  of  this  process  must  be  guaranteed.  This  implies  that  the  output  of 
this  process  is  not  interactive.  Rather,  it  is  a  simple  flow  of  data  in  one  direction,  from 
the  search  process  to  the  router  process. 

3.2.2  Broadcast  Site  Router  Process 

This  is  the  intelligent  bridge  connecting  the  source  of  VTS  information  and  the 
broadcast  system.  It  accepts  the  information  provided  by  the  VTS  Database  Search 
process  and  routes  that  information  to  the  appropriate  broadcast  site  or  sites. 
Considering  rules  designed  into  this  process  and  profiles  about  each  of  the  broadcast 
sites,  this  process  sorts  through  the  stream  of  information  provided  by  the  VTS 
Database  Search  process.  When  this  process  identifies  information  that  satisfies  all 
the  qualifying  criteria,  that  information  is  communicated  to  the  appropriate  broadcast 
site.  If  the  information  does  not  satisfy  all  the  distribution  criteria,  it  is  simply  deleted. 
This  process  does  not  maintain  a  permanent  database.  Once  information  is  processed, 
it  is  deleted.  The  VTS  information  is  communicated  to  the  Broadcast  Scheduler 
process  at  each  broadcast  site  using  the  methods  described  in  the  internal  system 
message  and  command  structure  standard. 

The  routing  of  VTS  information  to  the  appropriate  broadcast  sites  is  a  logical,  not  a 
mechanical,  process.  Routing  is  based  on  the  content  of  the  information.  The 
intelligence  to  make  routing  decisions  based  on  the  information  is  built  into  the  routing 
process.  Where  information  is  sent  may  depend  on  the  geographic  location  of  the 
information  and  the  area  covered  by  a  broadcast.  It  could  also  depend  on  the  type  of 
information  contained  in  the  message.  Routing  rules  and  the  basis  of  decisions  need 
to  be  developed  and  evaluated. 

The  separation  of  this  process  from  the  database  search  process  allows  changes  to  be 
made  to  the  broadcast  system  without  making  any  system  software  changes  to  the  VTS 
database  system  (JMCIS).  This  is  an  important  approach  that  minimizes  the  JMCIS 
costs  as  details  of  the  broadcast  system  evolve.  If  the  developmental  work  is  done 
correctly,  the  JMCIS  will  be  capable  of  supporting  a  Navigation  Safety  Broadcast 
service  at  the  end  of  the  research  phase. 
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3.2.3  Broadcast  Scheduler  Process 

The  broadcast  scheduler  accepts,  stores,  schedules,  and  delivers  VTS  information  to  a 
geographic  coverage  area.  It  also  maintains  a  permanent  record  of  the  information 
provided  by  the  broadcast,  and  it  provides  status  information  to  the  VTS  operator 
through  the  communications  network  side  of  the  system.  VTS  and  system  control 
information  is  accepted  from  any  number  of  routers  and  monitors.  This  information  is 
used  to  establish  and  maintain  a  database.  The  broadcast  scheduling  process  uses 
this  database.  Broadcast  Monitor  performance  assessments,  output  queue  status  and 
internal  rules  to  decide  what  and  when  information  should  be  broadcast.  The 
Broadcast  Scheduler  is  the  primary  work  horse  of  the  broadcast  system.  How  this 
process  performs  defines  the  service.  The  broadcasts  produced  by  this  process 
conform  to  the  structure  described  in  the  Navigation  Safety  Broadcast  standard. 

The  placement  of  the  Broadcast  Scheduler  at  the  broadcast  site  in  the  sample  design 
(section  3.1)  suggests  that  it  has  the  following  characteristics: 

The  Broadcast  Scheduler  operates  independently  of  other  broadcast  schedulers. 
In  particular,  the  content  of  the  broadcast  is  the  responsibility  of  only  the  site’s 
scheduler. 

The  communications  input  (modem  shown  in  Figure  6 )  is  a  gateway  capable  of 
accepting  information  simultaneously  from  multiple  site  routers  and  monitor 
processes. 

The  rate  that  information  arrives  at  the  broadcast  scheduler  cannot  be  controlled 
by  the  broadcast  scheduler  and  will  probably  be  greater  than  the  rate  at  which  it 
can  be  broadcast. 

The  VTS  database  information  may  be  provided  by  several  independent  VTS 
databases.  This  means  that  some  of  the  information  will  be  duplicated,  but  be 
stored  under  two  identities!  The  scheduling  process  needs  to  address  detection 
of  duplicate  information  in  the  database. 

The  scheduler  process  will  have  access  to  all  the  information  it  needs  to  score 
its  own  performance.  This  makes  it  possible  to  create  an  adaptable  scheduling 
process. 

Broadcasts  are  continuous  signals  and  operate  on  radio  navigation  frequencies 
or  public  broadcast  frequencies  protected  from  communications  signal  conflicts 
(unintentional  jamming  is  not  a  major  issue).  Broadcast  signals  are  assigned 
frequencies  and  power  levels  that  allow  continuous  operation  without 
interference  to  or  from  other  radio  signals. 

Early  establishment  of  performance  factors  should  be  based  on  an  assessment  of  what 
information  today’s  primary  VTS  users  need  (section  3.2.7).  The  performance  factors 
can  then  be  used  to  evaluate  (score)  alternative  approaches  to  scheduling.  Factors 
that  are  expected  to  affect  scheduling  performance  include:  the  capacity  of  the  physical 
transmitter  link  (bits  per  second),  the  size  of  messages,  the  bandwidth  gain  provided  by 
the  compression  method,  overhead  of  packet  ED&FEC/headers,  desired  information 
range  (information  range  is  expected  to  be  greater  than  the  working  range,  see  below), 
navigational  significance  of  the  information,  number  of  accelerating  targets,  number  of 
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moving  targets,  number  of  static  targets,  amount  of  static  information,  desired 
information  accuracy,  the  frequency  with  which  broadcast  errors  are  detected  by  the 
service  monitor,  density  of  marine  traffic  in  critical  maneuvering  areas,  the  age  of  the 
information,  how  often  static  messages  need  to  be  repeated,  etc.  Full  anticipation  of 
every  scheduling  possibility  is  expected  to  be  difficult.  Initial  work  will  need  to 
investigate  adaptive  processing  approaches  as  a  solution.  Development  and  testing  of 
alternative  scheduling  methods  and  processes  should  be  conducted  while  the 
supporting  standards,  methods,  and  processes  are  under  development. 

The  broadcast  will  have  a  working  range  and  an  information  range.  The  range  circles 
in  Figures  6  and  8  are  the  working  range  of  the  transmitter  signals.  The  working  range 
of  the  broadcast  (also  called  coverage  range)  is  the  distance  at  which  some  percentage 
of  the  broadcast  messages  can  be  received  (using  FEC)  on  some  statistical  average. 

An  acceptable  percentage  will  need  to  be  determined.  The  information  range  of  the 
broadcast  is  addressing  the  content  of  the  broadcast.  Users  are  expected  to  be 
interested  in  information  outside  the  coverage  of  the  broadcast  as  they  navigate  away 
from  the  broadcast  site.  The  area  that  a  Broadcast  Scheduler  is  expected  to  cover  with 
respect  to  information  will  be  larger  than  the  working  range.  In  general,  the  Broadcast 
Site  Router  will  provide  information  based  on  the  information  range  of  a  broadcasting 
site  rather  than  the  working  range. 

3.2.4  Broadcast  Monitor  Process 

Broadcast  monitors  are  installed  to  assess  the  real  time  effectiveness  of  the  service. 
Using  the  content  of  received  messages  and  automated  methods,  the  Broadcast 
Monitor  process  provides  real  time  control  information  to  the  Broadcast  Scheduler 
process,  status  and  warning  information  to  the  VTS  operators,  and  maintains  historic 
records  concerning  the  information  received  in  the  coverage  area  and  the  performance 
of  the  broadcast  system.  The  true  benefit  of  the  monitor’s  real  time  ability  to  request 
the  retransmission  of  specific  packets  will  have  to  be  assessed  after  the  reliability  of  the 
radio  signal  and  FEC  can  be  determined. 

The  monitor  site  should  be  located  near  the  limit  of  the  transmitter’s  working  range. 

Each  transmitted  signal  should  be  monitored  by  a  separate  monitor  process.  Co- 
located  monitoring  would  be  done  using  separate  equipment.  The  overall  broadcast 
system  should  be  designed  to  continue  to  operate  even  when  the  monitor  is  unable  to 
function  as  part  of  the  system.  The  Broadcast  Monitor  process  communicates  with  the 
Broadcast  Scheduler  using  the  methods  described  in  the  internal  system  message  and 
command  structure  standard. 

3.2.5  Internal  Broadcast  System  Standard 

This  is  a  document  describing  the  information  and  command  signals  communicated 
between  elements  of  the  system.  Because  the  internal  communications  can  be 
designed  using  existing  network  communications  standards  and  services,  this  standard 
will  primarily  contain  high  level  information.  Communications  details  will  be  more 
useful  as  specifications  for  purchased  services;  not  part  of  the  standard.  The  standard 
is  used  by  the  process  and  system  designers  to  construct  and  maintain  the  system. 
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3.2.6  Broadcast  Message  Structure 

The  broadcast  message  structure  will  need  to  be  completely  described  in  a  standard. 
This  standard  will  describe  both  the  signal  characteristics  and  the  information  content 
of  the  broadcast.  Development  of  a  Navigation  Safety  Broadcast  (NSB)  standard  will 
be  a  significant  effort.  This  document  describes  ever^hing  a  potential  equipment 
manufacturer  needs  to  know  about  the  transmitted  “signals  in  space  produced  by  the 
service.  It  is  used  to  build  receiving  equipment  that  intercepts  the  transmitted  signals 
and  software  that  presents  the  broadcast  information  to  the  user.  The  methods 
described  below  (sections  3.2.6. 1  -  3.2.6.6)  would  be  a  portion  of  the  information 
contained  in  this  document.  The  document  would  also  contain  a  description  of  all  of 
the  information  provided  in  the  broadcast  with  instructions  on  how  the  information 
should  be  used. 

In  addition  to  this  document,  it  may  be  beneficial  to  plan  to  provide  samples  of  software 
and  data  sets  that  manufacturers  can  use  during  equipment  development.  Previous 
USCG  R&D  experience  with  the  development  of  Differential  GPS  equipment  and 
software,  showed  that  assistance  of  this  type,  shortened  the  commercial  development 
process  and  improved  the  quality  of  the  first  products.  Impartial  testing  of 
developmental  commercial  products  is  another  means  that  has  been  successfully  used 
to  encourage  commercial  efforts  and  to  guarantee  quality  products. 

3.2.6.1  Message  Compression  Method 

The  purpose  of  data  compression  is  to  reduce  the  length  of  the  bit  string  representing  a 
message  without  compromising  any  of  the  information  in  the  message.  Data 
compression  allows  more  information  to  be  broadcast  using  a  fixed  number  of  data  bits. 
This  increases  the  amount  of  information  the  Broadcast  Scheduler  can  transmit  in  a 
given  time  interval.  The  advantage  of  increasing  the  capacity  of  the  broadcast  channel 
is  slightly  offset  by  the  increased  processing  burden  placed  on  both  the  transmitting 
and  receiving  ends. 

This  form  of  compression  (at  the  OSI  model  level)  is  a  mechanical  method  that  works 
on  the  bits  of  information  in  the  message  without  knowing  what  the  information  is.  The 
committee  that  develops  the  message  structure  for  the  NSB  standard  will  need  to 
address  the  question  of  how  message  information  should  be  represented.  It  is  the 
responsibility  of  the  NSB  standard  committee  to  use  heuristic  or  logical  methods  to 
represent  the  message  information  in  a  compact  form  prior  to  the  mechanical 
compression  process.  Creating  compact  message  structures  for  the  NSB  standard  will 
improve  the  capacity  of  the  broadcast  channel. 

3.2.6.2  Message  Encryption  Method 

Message  encryption  limits  access  to  information.  There  are  several  reasons  why  this 
capability  should  be  included  in  the  design  of  a  broadcast  system.  It  could  be  used 
selectively  to  limit  the  distribution  of  some  of  the  information  being  broadcast.  This 
might  be  necessary  for  port  security  reasons.  It  could  also  be  used  to  limit  information 
distribution  to  those  who  have  paid  a  service  fee.  If  included  in  the  design,  policy 
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decisions  concerning  how  this  capability  is  used  can  be  made  as  circumstances 
warrant  during  the  operation  of  the  system. 

Denial  of  access  to  all  the  information  would  bring  into  question  the  “navigation  service" 
quality  of  this  broadcast.  In  particular,  if  protected  international  navigation  frequencies 
are  used  as  the  broadcast  channel,  the  signal  would  be  expected  to  be  made  available 
to  the  general  public.  However,  partial  denial  of  certain  information  could  be  viewed  as 
a  necessary  feature  of  even  a  navigation  service  if  it  is  necessary  to  protect  port 
security.  An  example  is  the  DOD  selective  availability  on  the  GPS  signal. 

The  method  selected  should  provide  for  a  large  number  of  possible  keys.  Operating 
the  service  with  a  mix  of  encrypted  and  open  messages  should  be  considered  normal. 
For  example,  an  open  message  can  be  followed  by  a  secure  message  that  is  followed 
by  a  message  with  a  service  charge.  Use  of  encryption  keys  should  not  cause 
malfunctions  in  unkeyed  user  equipment.  It  should  be  possible  to  use  the  same 
broadcast  channel  for  time  multiplexed  open,  secure,  and  cost  recovery  messages. 

3.2.6.3  Packetizing  Method 

Error  detection  and  forward  error  correction  (ED&FEC,  see  section  3.2.6.4)  methods 
are  easier  to  understand  and  implement  if  they  operate  on  a  fixed  number  of  bits.  In 
fact,  there  are  optimal  numbers  of  bits.  The  selected  packetizing  method  breaks  the 
continuous  stream  of  coded  compressed  encrypted  messages  into  chunks  of  bits  that 
can  be  protected  with  a  ED&FEC  method.  The  use  of  message  packets  produces 
groups  of  bits  that  can  be  enveloped  in  a  frame  containing  a  header  and  ED&FEC 
information.  The  packet  header  contains  sequence  information  that  allows  the  received 
bits  to  be  routinely  arranged  in  proper  order  even  if  the  packets  are  received  out  of 
order. 

The  use  of  packets  allows  the  recovery  of  larger  messages  without  retransmitting  the 
entire  message.  The  Broadcast  Monitor  will  request  missed  information  to  be 
rebroadcast  at  the  packet  level.  Selecting  the  optimal  number  of  bits  in  a  packet  will 
need  to  take  into  consideration  a  number  of  factors;  for  example,  the  data  rate  of  the 
transmitter,  the  nature  of  the  electronic  noise,  the  characteristics  of  the  propagation 
medium,  broadcast  monitor  operation,  and  the  time  it  takes  to  signal  the  Broadcast 
Scheduler  to  retransmit  a  packet.  The  analysis  of  the  packet  size  options  and  ED&FEC 
methods  will  require  the  use  of  both  modeling  methods  and  physical  signal 
measurements  at  the  potential  broadcast  frequencies. 

3.2.6.4  Error  Detection  and  Forward  Error  Correction  Method 

Error  detection  (ED)  provides  a  way  to  recognize  a  corrupted  packet  of  data  when  it 
arrives.  Error  detection  protects  the  receiving  system  from  suffering  the  consequences 
of  using  an  incorrect  packet  of  information. 

Forward  error'correction  (FEC)  provides  a  way  to  correct  corrupted  information. 
Calculations  are  performed  on  the  broadcast  information  before  it  is  transmitted.  The 
resulting  correction  parameters  are  sent  along  with  the  information  by  adding  extra  bits 
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to  the  transmitted  signal.  The  reception  process  uses  the  correction  parameters  to 
correct  errors  in  the  received  information.  Forward  error  correction  success  is  limited. 

It  provides  a  mechanism  for  recovering  information  only  when  a  few  bits  of  information 
are  in  error.  The  Broadcast  Monitor  (section  3.2.4)  will  only  be  able  to  detect  some  of 
the  coverage-area-wide  data  corruption  problems.  There  will  be  localized  problems 
that  the  Broadcast  Monitor  will  not  detect.  FEC  will  provide  a  way  to  recover  from  some 
of  these  local  problems.  If  the  Broadcast  Monitor  process  is  not  included  in  the  final 
system  design,  FEC  will  be  the  only  corrective  option  other  than  waiting  for  the  next 
transmission  of  the  missed  message. 

3.2.6.5  Packet  Framing  Structure  Method 

The  packet  framing  structure  is  used  to  code  the  transmitted  signal  in  such  a  way  that 
the  receiving  equipment  is  able  to  identify  the  various  bits  of  a  continuously  broadcast 
signal.  The  framing  structure  provides  delineation  of  a  frame's  start  and  end  and  also 
includes  the  ED&FEC  bits  for  the  packet.  It  provides  a  timing  point  that  can  be 
identified  and  used  to  begin  sorting  out  the  received  bits  based  upon  time.  This  is  how 
the  identities  of  the  received  bits  are  established. 

3.2.6.6  Radio  Transmission  Method  and  Frequency  Plan 

This  contains  the  detailed  electronic  information  needed  by  manufacturers  building 
products  designed  to  use  the  broadcasts.  It  also  describes  how  the  bits  of  information 
will  be  represented  in  the  broadcast  signal.  The  signal  characteristics  and  frequency 
usage  plan  are  important  to  design  engineers  as  well  as  spectrum  managers 
concerned  about  possible  problems  being  created  between  this  and  existing  services. 

3.2.7  Broadcast  Information  Presentation  Process 

Presently,  VTS  information  is  distributed  using  voice  communications.  Therefore,  pilots 
have  become  conditioned  to  requesting  and  obtaining  information  that  can  be 
understood  using  their  sense  of  hearing.  The  information  distributed  using  the 
Navigation  Safety  Broadcast  proposed  by  this  report  will,  more  likely  than  not,  be 
delivered  visually.  Will  the  pilot  have  to  adapt  his  process  from  hearing  information  to 
seeing  it,  or  will  the  computers  be  expected  to  carry-on  a  conversation  with  the  pilot? 

The  purpose  of  the  Broadcast  Information  Presentation  process  is  to  convert  the  “bits 
and  bytes”  of  the  received  messages  described  in  the  Navigation  Safety  Broadcast 
standard  into  some  form  that  a  user  can  understand  without  having  to  reference  the 
standard.  The  Electronic  Chart  System  (ECS)  shown  as  the  destination  of  the  digital 
broadcast  in  Figure  4  is  an  example  of  such  a  visual  presentation  process.  To  date, 
the  USCG  view  of  VTS  information  has  been  conditioned  by  the  responsibilities  of  the 
VTS  operator.  This  does  not  provide  much  insight  into  how  a  pilot  will  view  the  same 
information.  The  pilot’s  responsibilities  are  different.  What  a  pilot  will  see  in  the  VTS 
information  and  how  long  it  will  take  to  see  it,  depends  on  what  they  expect  to  get  out  of 
the  information.  Little  is  understood  about  what  a  pilot  will  want  to  see  and  how  they 
will  want  it  presented,  yet  their  understanding  of  the  VTS  information  is  a  critical  factor 
in  the  success  of  this  entire  digital  broadcasting  approach. 
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An  investigation  needs  to  be  done  on  how  pilots  will  transition  from  hearing  to  seeing 
VTS  information.  Does  this  sensory  change  alter  their  information  needs?  This 
investigation  is  needed  to  ensure  that  the  required  VTS  information  is  being  adequately 
broadcast  and  that  the  shift  in  sensory  workload  does  not  work  to  the  detriment  of  the 
overall  objective  of  a  safer  more  efficient  waterway.  Questions  that  this  investigation 
should  address  include; 

-  What  is  the  present  “VTS  workload”  for  a  marine  pilot?  That  is;  how  does  present 
VTS  interaction  impact  a  pilot  (percentage  of  workload)? 

-  What  impact  would  a  visual  interface  containing  “automated  VTS  information”  have 
on  his  workload? 

-  Will  the  NSB  simply  transfer  VTS  operator  workload  to  the  pilots? 

-  What  information  do  pilots  want  and  how  do  they  want  the  information  delivered? 

-  What  features  should  the  pilot  system  have? 

-  What  VTS  information  does  the  pilot  need  to  understand? 

-  Does  the  NSB  result  in  an  overall  workload  reduction  or  increase  for  the  pilot? 

In  addition  to  the  human  interface  there  are  a  number  of  technical  issues  that  the  users 
electronic  application  processes  must  address.  For  example,  the  application  may  be 
capable  of  receiving  multiple  broadcasts.  If  this  is  a  capability,  the  application  must  be 
able  to  routinely  handle  duplicate  information  arriving  from  independent  broadcasts. 

The  VTS  database  should  be  treated  as  a  separate  information  layer  in  an  ECS  or  IMO 
Electronic  Chart  Display  Information  System  (ECDIS).  The  information  should  not  be 
integrated  with  the  chart  database.  The  “half-life”  of  the  information  is  much  too  short. 

It  does  not  have  the  same  temporal  stability  as  the  chart  data.  Functions  and  features 
of  the  ECS  or  ECDIS,  that  require  the  combination  of  chart  and  VTS  information, 
should  perform  their  calculations  by  drawing  their  inputs  from  the  two  separate 
databases  at  the  time  of  the  calculation.  The  details  of  how  the  VTS  data  should  be 
presented  on  top  of  the  ECS  or  ECDIS  chart  backdrop  is  also  an  area  requiring  more 
research.  This  question  has  not  been  addressed  by  either  the  IMO-ECDIS  or  RTCM- 
ECS  committees. 

Finally,  the  broadcast  and  communications  links  between  the  VTS  database  and  the 
user  application  (such  as  the  ECS  in  Figure  4 )  are  intended  to  compliment  each  other. 
Work  needs  to  be  done  to  investigate  the  future  features  of  an  ECS  (or  ECDIS)  that 
may  need  to  access  the  VTS  database  though  a  communications  connection. 
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3.3  Broadcast  System  Design  Issues 

In  the  process  of  creating  and  describing  the  sample  design  in  Figures  6  and  8,  some 
issues  could  not  be  presented  under  a  particular  process,  standard,  or  method  section. 
These  system  level  issues  are  presented  here  for  future  consideration. 

The  sample  design  that  has  been  presented  assumed  that  broadcast  sites  transmitted 
on  a  single  channel.  Research  into  multi-frequency  broadcasts  may  produce  system 
wide  benefits.  Besides  the  obvious  benefit  of  increased  information  capacity, 
broadcasts  on  multiple  frequencies  unleash  the  many  options  of  OSI  model  layer  3,  the 
network  layer.  In  this  report,  the  contribution  of  layer  3  was  minimal  due  to  the  fact  that 
no  “network  options”  are  available  when  transmissions  are  limited  to  a  single 
frequency. 

What  the  user  sees  and  understands  as  a  result  of  receiving  the  NSB  is  the  key  to 
realizing  the  desired  benefits  from  distributing  digital  VTS  information.  The 
understanding  is  conveyed  to  the  user  through  the  interpretation  of  the  shipboard 
display  system.  Some  investigation  into  ways  to  guarantee  the  performance  of  the 
shipboard  electronics  and  software  needs  to  be  done.  The  objective  of  the 
investigation  would  be  to  determine  ways  that  guarantee  that  what  the  user  sees  on  the 
display  conveys  the  understanding  that  is  contained  in  the  VTS  information  being 
broadcast.  What  are  viable  options?  Should  the  USCG  develop  and  “give-away” 
software  that  must  be  used?  Will  equipment  “type  acceptance”  be  necessary?  Could 
some  existing  commercial  quality  assurance  program  be  used? 
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4.0  Conclusions 

Implementation  of  the  voiceless  vessel  traffic  service  concept  will  require  the 
development  of  new  or  the  identification  and  review  of  existing  processes,  standards, 
and  methods  that  can  be  used  to  create  the  service.  Because  the  voiceless  vessel 
traffic  service  concept  is  based  on  the  automatic  distribution  of  VTS  information,  a  fresh 
review  of  how  information  is  entered  into  the  vessel  traffic  service  database  will  be 
needed  to  reaffirm  that  the  information  in  the  database  undergoes  sufficient  validation 
and  is  suitable  for  automatic  distribution.  An  assessment  of  the  sensitivity  of 
information  in  the  database  should  also  be  done  to  determine  if  open  and  automatic 
distribution  of  that  information  will  compromise  the  present  levels  of  port  security. 

The  voiceless  vessel  traffic  service  model  suggests  the  use  of  two  complementary 
methods  for  the  automated  distribution  of  information,  wireless  digital  communications 
and  wireless  digital  broadcasting.  Presently,  the  telecommunications  industry  is 
investing  heavily  in  the  development  of  bi-directional  wireless  communications 
services.  Significant  government  funding  for  voiceless  VTS  development  of  wireless 
digital  communications  technology  is  not  presently  required.  The  development  of 
digital  broadcast  methods  is  not  receiving  the  same  level  of  telecommunications 
industry  support.  The  processes,  standards,  and  methods  needed  to  deploy  a  VTS 
digital  navigation  safety  broadcast  will  require  government  support. 

There  are  two  factors  that  favor  the  use  of  broadcasts  for  the  distribution  of  navigation 
information.  The  first  factor  is  the  cost  to  the  user.  In  general,  the  Unites  States  does 
not  charge  for  navigation  signals.  The  user  needs  to  make  only  a  “one-time” 
investment  in  equipment.  On  the  other  hand,  wireless  telecommunications  services 
charge  usage  fees.  The  second  factor  is  the  ability  of  broadcasts  to  simultaneously 
distribute  the  same  information  to  an  unlimited  number  of  users.  Broadcast  capacity  is 
independent  of  user  demand.  Communications  channels  can  become  saturated  and 
fail  as  demand  increases.  Demand  for  navigation  information  is  expected  to  be  the 
highest  when  navigating  conditions  are  the  worst.  Potential  failure  of  the  voiceless 
VTS  navigation  information  link  during  high  demand  is  not  a  desired  voiceless  VTS 
characteristic. 

A  simple  model  of  a  NSB  system  was  developed  and  used  to  help  identify  areas 
requiring  development.  The  following  processes  were  found  to  be  necessary  to  create 
a  simple  design  of  a  voiceless  VTS  navigation  safety  broadcast: 

VTS  Database  Search  -  This  intercepts  and  forwards  validated  VTS  database 
information  to  the  “Broadcast  Site  Router.”  This  process  should  be  designed  to  be 
a  minimum  load  on  an  existing  VTS  database  management  process. 

Broadcast  Site  Router  -  This  accepts  information  provided  by  the  “VTS  Database 
Search”  and  reviews  the  content  of  the  information.  If  the  information  is  appropriate 
for  distribution,  it  is  forwarded  to  the  “Broadcast  Scheduler”  at  each  appropriate 
broadcast  site. 
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Broadcast  Scheduler  -  This  accepts  information  provided  by  the  “Broadcast  Site 
Routers”  and  enters  it  into  its  local  database.  Using  the  local  database,  information 
from  the  “Broadcast  Monitors”,  and  internal  strategy  objectives,  it  prepares  and 
broadcasts  VTS  messages. 

Broadcast  Monitor  -  This  gathers  the  navigation  safety  broadcast  information  off  the 
airwaves  much  as  a  VTS  NSB  user  equipment  would.  It  monitors  performance  and 
detects  specific  problems  that  can  be  corrected  by  the  “Broadcast  Scheduler.”  It 
provides  reports  directly  to  the  "Broadcast  Scheduler”  for  each  broadcast  site  it 
monitors. 

Two  standards  describing  the  operation  of  the  system  are  needed.  The  first  standard 
would  describe  the  internal  system  message  and  command  structure  of  the  system. 

This  would  be  used  to  design  and  maintain  the  system.  The  second  standard  provides 
everything  a  potential  equipment  manufacturer  would  need  to  know  about  the 
broadcast  signal  in  order  to  manufacture  user  equipment.  A  number  of  methods  need 
to  be  developed  or  identified  to  support  these  standards.  They  include: 

Message  Compression  method  -  This  improves  the  broadcast  channel  efficiency 
thus  increasing  the  information  capacity. 

Message  Encryption  method  -  This  opens  the  operational  capability  to  broadcast 
information  to  a  limited  group  of  users. 

Packetizino  method  -  This  establishes  how  the  broadcast  bits  are  organized  for 
transmission  and  forward  error  correction  schemes. 

Error  Detection  and  Forward  Error  Correction  method  -  This  protects  the  user’s 
system  from  being  infected  by  erroneous  information. 

Packet  Framing  Structure  method  -  This  establishes  how  the  transmitted  information 
can  be  recovered  from  the  intercepted  signal. 

Radio  Transmission  method  and  Frequency  Plan  -  This  establishes  how  the  user’s 
radio  receiving  equipment  needs  to  be  designed. 

Automating  the  distribution  of  information  reduces  the  voice  radio  communications 
between  the  vessel  pilots  and  vessel  traffic  service  operator.  This  is  viewed  as  a 
workload  reduction  for  the  operator,  but  the  shift  of  the  “vessel  traffic  service  workload” 
for  the  pilot.  The  significance  of  this  shift  is  not  well  understood.  The  impact  of 
automation  on  the  pilot  as  a  result  of  this  switch  from  aural  distribution  to  visual 
presentation  needs  investigation.  The  study  is  needed  to  report  the  change  in  piloting 
workload,  impact  on  marine  safety,  and  the  benefits  of  this  approach.  The  pilot’s  views 
on  the  information  content  and  shipboard  presentation  are  needed  to  develop  the  most 
appropriate  shipboard  presentation. 
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Future  USCG  research  should  include  a  demonstration  in  the  form  of  a  “voiceless  VTS 
test  bed”  conducted  with  the  cooperation  of  an  operating  USCG  VTS  and  the  marine 
pilots  association  working  in  their  vessel  traffic  service  area.  This  demonstration  would 
provide  an  opportunity  to  develop  and  evaluate  the  needed  voiceless  vessel  traffic 
services  processes  and  standards.  It  would  also  provide  an  opportunity  to  work  with 
the  pilots  to  develop  the  true  information  requirements  for  the  navigation  safety 
broadcast’s  content  and  scheduling  strategies.  The  demonstration  would  serve  as  a 
vehicle  for  standards  and  equipment  development  in  cooperation  with  the  industry  that 
would  support  future  operational  deployment  of  voiceless  vessel  traffic  services. 


4.1  Recommendations 


1 .  Establish  a  cooperative  effort  between  the  USCG  VTS  Upgrade  (JMCIS)  project 
and  the  R&D  VTS  project  to  add  a  new  capability  to  JMCIS.  The  desired 
characteristics  of  this  capability  are  described  in  section  3.2.1  (VTS  Database 
Search  Process).  Installation  and  operation  of  this  new  JMCIS  capability  at  an 
existing  USCG  VTS  would  greatly  reduce  the  R&D  costs  for  voiceless  VTS 
experimentation. 

2.  Establish  a  Cooperative  Research  And  Development  Agreement  (CRADA)  that 
supports  investigation  of  actual  digital  broadcast  issues  and  the  pilot’s  VTS 
information  display  requirements  (see  section  3.2.7).  The  goal  of  the  CRADA  is 
demonstration  of  a  proof-of-concept  digital  navigation  safety  broadcast  and  an 
evaluation  of  its  benefits  for  commercial  pilots.  This  agreement  would  include  an 
existing  USCG  VTS  command  and  the  pilots  operating  in  their  vessel  traffic 
service  area. 

3.  With  the  cooperation  of  the  Radio  Technical  Commission  for  Maritime  services 
(RTCM),  establish  a  working  group  that  would  develop  a  standard  describing  the 
signal  and  content  of  the  digital  VTS  Navigation  Safety  Broadcast.  This  group 
would  contain  representatives  from  government,  industry,  and  academia.  The 
work  of  this  group  would  address  the  issues  described  in  section  3.2.6 
(Broadcast  Message  Structure). 

4.  Continue  to  investigate,  develop,  and  test  alternative  methods  and  software 
needed  to  implement  the  internal  USCG  broadcast  information  and  control 
structure  described  in  sections  3.2.2  through  3.2.5. 

5.  Establish  a  new  R&D  effort  to  investigate  and  develop  alternative  VTS  sensors 
that  would  automate  validation  of  the  VTS  database  contents  (see  section  2.2). 

6.  Establish  a  new  R&D  effort  to  evaluate  the  future  information  needs  of  voiceless 
VTS  users  and  the  delivery  methods  that  minimize  the  impact  on  their  workload 
(see  section  3.2.7). 
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